2015-06-15 DNSSEC failures
The original version of this entry was published in 2014 July. Some of the DNS failures in that version have been corrected, but these are still failing.
Fail - no DS records in the parent zone
Consider csnchicago.com - aka Comcast Sports Net Chicago. They apparently consider DNSSEC important enough to bother signing their own records. But they have omitted the required step of placing their DS records in the .com zone. So their signatures are useless. See this for the details.
They have the same error for csnbaltimore.com, csnbayarea.com, csncalifornia.com, csnchicago.com, csnhouston.com, csnne.com, csnnw.com, csnphilly.com, csnwashington.com and comcastsportsnet.com.
Consider truste.com - Powering Trust in the Data Economy. Right. So they sign their zone, but again fail to put the DS records into the .com zone. So their signatures are useless. See this for the details.
The following all have the same failure - where.com, incommon.org
Fail - path mtu issues
Consider export.gov. See this for details. They are apparently trying to send packets that exceed their own path mtu.
Fail - expired signatures
Consider validatorsearch.verisignlabs.com. The parent verisignlabs.com contains a proper DS record for validatorsearch, and the parent has properly signed that DS record. The validatorsearch.verisignlabs.com contains the matching DNSKEY record, but the RRSIG signature on that DNSKEY record expired about 21 months ago. All the other signatures also expired at about the same time. See this for the details.
Fail - broken dns servers
Yet another type of failure is caused by the use of a broken dns server that does not understand EDNS options. Consider phantom.eia.gov. The eia.gov dns servers include 205.254.135.9 and 199.36.140.199. So we ask them some questions:
dig phantom.eia.gov. @205.254.135.9 +dnssec +norecur ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30660 ;; flags: qr aa ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 dig phantom.eia.gov. @205.254.135.9 +dnssec +nsid +norecur ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20 ;; flags: qr ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
Those servers choke on EDNS options, which is just wrong.
Consider washjeff.edu. The washjeff.edu dns servers include 209.131.83.17 and it responds with:
dig @209.131.83.17 washjeff.edu soa +dnssec +norecur ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45399 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 dig @209.131.83.17 washjeff.edu soa +dnssec +norecur +nsid ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 16438 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
Those servers choke on EDNS options, which is just wrong. The same issue may affect: pl pw 103.in-addr.arpa 210.in-addr.arpa com.es com.my dimewallet.com sourceware.org
Consider newsrss.bbc.net.uk. The bbc.net.uk dns servers include 212.58.240.162, so we ask some questions.
dig newsrss.bbc.net.uk a @212.58.240.162 +nodnssec +norecur ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 24230 ;; flags: qr aa ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: EDNS query returned status FORMERR - retry with '+noedns' ;; WARNING: Message has 11 extra bytes at end dig newsrss.bbc.net.uk a @212.58.240.162 +nodnssec +noedns +norecur ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1924 ;; flags: qr aa ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;newsrss.bbc.net.uk. IN A ;; ANSWER SECTION: newsrss.bbc.net.uk. 300 IN CNAME news.bbc.co.uk.edgesuite.net.
They don't understand EDNS at all, but most modern DNS servers will start by including EDNS options. So everyone needs to ask their questions twice. Clever.